AWSサブネットの切り方を考えてみた

サブネットの切り方について考えてみる

#Amazon VPC

#subnet

#AWS

吉井亮

2021.07.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きなネクストモード株式会社の吉井です。

直近のプロジェクトで「サブネットをどうやって切ればいいか」を議論したので私の意見をまとめてみました。

AWSのサブネットとは

このエントリを読んでくださっている方で AWS のサブネットを知らない方はいらっしゃらないと思うので簡単に振り返ります。

サブネットは VPC 内に作成します。
Availability Zone ごとに作成します。Availability Zone をまたいだサブネットを作ることはできません。

IPv4 VPCとサブネットのサイズ

VPC は以下の IP アドレスレンジから /16 ～ /28 のブロックサイズで作成します。

10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255

サブネットは作成した VPC のアドレスレンジの範囲で切り出していきます。
サブネットのブロックサイズも /16 ～ /28 の間で選択します。

これを言いたいがために基本的な説明をしたのですが、
各サブネット CIDR ブロックの最初の 4 つの IP アドレスと最後の IP アドレスは AWS に予約されています。

最初の1つ (例 10.0.0.0) = ネットワークアドレス
2つ目 (例 10.0.0.1) = VPC ルーター用
3つ目 (例 10.0.0.2) = AWS で予約、VPC CIDR にプラス2したものは Amazon DNS サーバー
4つ目 (例 10.0.0.3) = 将来利用
最後 (例 10.0.0.255) = ネットワークブロードキャストアドレス

サブネットの切り方

AWS でサブネットを切る際に何を基準に考えたら良いでしょうか？
オンプレミスの場合ではネットワークの分離、トラフィックやセキリュティ、を重点に考えていたように思います。

AWS サブネットの場合は ルートテーブル と NACL を基準にサブネット切ります。

私はルートテーブルを基準にすることがほとんどです。
通信先の制御というのが主な理由です。
AWS リソースをインターネットから隠したい (INもOUTも) ときには Private Subnet を作ってそこに置くのが手っ取り早く確実です。
Direct Connet 等でオンプレミスと接続する場合、VPC Peering で他 VPC を接続する場合も接続の必要が無いリソースを同じサブネットに置きたくありません。

ルートテーブルを基準にサブネットを切る例を示します。

名称	概要
Public Subnet	Internet Gateway へのルートを持つ
Private Subnet	Internet へのルートを持たない
Nat Subnet	NAT Gateway へのルートを持つ
Transit Subnet	Transit Gateway へアタッチする
Internal Subnet	Direct Connect や VPN でオンプレミスと接続する
LB Subnet	ALB, NLB 専用のサブネット

ルートテーブル基準の他にも以下のような理由でサブネットの切り方を工夫します。

意図しないルートに吸い込まれないようにする (Trangit Gateway)
IP アドレスの枯渇を嫌う (ALB)
Security Group が使えない (NLB)

サブネットとAvailability Zone

システムは Multi-AZ で組みたいものです。
どの AZ に置くかということに悩む人は少ないかもしれません。
ほとんどは2つ、東京リージョンだと AZ-A と AZ-C が多いように思います。

私のお薦めは 全ての AZ に置く です。
外部接続の都合などで VPC CIDR を狭くしないとならないケースを除いて、VPC CIDR を大きくとり数多くのサブネットを作れるようにしておくべきです。

その理由の1つは AZ 障害発生時の切り離しを素早く行うためです。
詳しくは以下のエントリを参照ください。

もう1つの理由がリソースの枯渇です。
AWS は無制限にリソースを使えるわけではありません。
空きが無い場合はオンデマンドで使用することができません。
特に新しいインスタンスタイプ、古すぎるインスタンスタイプは注意が必要です。
このリソース枯渇を回避するために全ての AZ でサブネットを作り、どの AZ でもリソースが起動できるようにしておきます。

サブネットCIDR

サブネットの切り方基準、AZ 配置が決まったところで CIDR はどうすればいいでしょうか。
リソースの必要数に合わせて十分なレンジを考えればよいのですが
ここにもちょっとしたこだわりがあります。

/nn で表現できる形にしよう です。

例えば以下のようにしておけば、Public と Private が /17 で表現できるようになります。
Security Group ルールを書く際に1行で済みます。ルールも無限に書けるわけではないのでこういう考慮は必要です。

Public Subnet (10.0.0.0/17)
- 10.0.0.0/24
- 10.0.1.0/24
- 10.0.2.0/24
Private Subnet (10.0.128.0/17)
- 10.0.128.0/24
- 10.0.129.0/24
- 10.0.130.0/24

実際はどうしているのか

AWS サブネットは 数少なくフラット が良いと考えます。
Dicect Connet 等の外部接続がなければ Public Subnet と Private Subnet の2種類で済むと思います。

オンプレミスで成功経験を多く積んでいると、業務 LAN、運用 LAN、DB LAN、DMZ など細かくサブネットを切ってしまいがちです。
もちろん細かく切っては駄目と言っているわけではありません。
ただ、AWS はサブネットを切るごとに 5つの IP アドレスを予約してしまいます。
IP アドレスを潤沢に確保できるなら問題ありませんが、そうでない場合はサブネットを切りすぎることが足かせになる可能性はあります。
ルートテーブルと NACL が同じサブネットであれば細かく切る意味はありません。